home *** CD-ROM | disk | FTP | other *** search
/ Skunkware 5 / Skunkware 5.iso / lib / calc / help / todo < prev    next >
Text File  |  1995-07-17  |  9KB  |  242 lines

  1. Needed enhancements
  2.  
  3.     Send calc comments, suggestions, bug fixes, enhancements and
  4.     interesting calc scripts that you would like you see included in
  5.     future distributions to:
  6.  
  7.         dbell@canb.auug.org.au
  8.         chongo@toad.com
  9.  
  10.     The following items are in the calc wish list.  Programs like this
  11.     can be extended and improved forever.
  12.  
  13.     *  Implement an autoload feature.  Associate a calc library filename
  14.        with a function or global variable.  On the first reference of
  15.        such item, perform an automatic load of that file.
  16.  
  17.     *  Use faster multiply and divide algorithms for large numbers.
  18.  
  19.     *  Add error handling statements, so that QUITs, errors from the 
  20.        'eval' function, division by zeroes, and so on can be caught.
  21.        This should be done using syntax similar to:
  22.  
  23.             ONERROR statement DO statement;
  24.  
  25.        Something like signal isn't versatile enough.
  26.  
  27.     *  Add a debugging capability so that functions can be single stepped,
  28.        breakpoints inserted, variables displayed, and so on.
  29.  
  30.     *  Figure out how to write all variables out to a file, including
  31.        deeply nested arrays, lists, and objects.
  32.  
  33.     *  Implement pointers.
  34.  
  35.     *  Eliminate the need for the define keyword by doing smarter parsing.
  36.  
  37.     *  Allow results of a command (or all commands) to be re-directed to a 
  38.        file or piped into a command.
  39.  
  40.     *  Add some kind of #include and #define facility.  Perhaps use
  41.        the C pre-processor itself?
  42.  
  43.     *  Allow one to undefine anything.  Allow one to test if anything
  44.        is defined.
  45.  
  46.     *  Support a more general input and output base mode other than
  47.        just dec, hex or octal.
  48.  
  49.     *  Allow support of POSIX bc via a translator reads bc commands, 
  50.        converts it to calc and pipes it into calc.
  51.  
  52.     *  Implement a form of symbolic algebra.  Work on this has already
  53.        begun.  This will use backquotes to define expressions, and new
  54.        functions will be able to act on expressions.  For example:
  55.  
  56.            x = `hello * strlen(mom)`;
  57.         x = sub(x, `hello`, `hello + 1`);
  58.         x = sub(x, `hello`, 10, `mom`, "curds");
  59.         eval(x);
  60.  
  61.        prints 55.
  62.  
  63.     *  Place the results of previous commands into a parallel history list.
  64.        Add a binding that returns the saved result of the command so
  65.        that one does not need to re-execute a previous command simply
  66.        to obtain its value.
  67.  
  68.        If you have a command that takes a very long time to execute,
  69.        it would be nice if you could get at its result without having
  70.        to spend the time to reexecute it.
  71.  
  72.     *  Add a binding to delete a value from the history list.
  73.  
  74.        One may need to remove a large value from the history list if
  75.        it is very large.  Deleting the value would replace the history
  76.        entry with a null value.
  77.  
  78.     *  Add a binding to delete a command from the history list.
  79.  
  80.        Since you can delete values, you might as well be able to
  81.        delete commands.
  82.  
  83.     *  All one to alter the size of the history list thru config().
  84.  
  85.        In some cases, 256 values is too small, in others it is too large.
  86.  
  87.     *  Add a builtin that returns a value from the history list.
  88.        As an example:
  89.  
  90.         histval(-10)
  91.     
  92.        returns the 10th value on the history value list, if such 
  93.        a value is in the history list (null otherwise).  And:
  94.  
  95.         histval(23)
  96.     
  97.        return the value of the 23rd command given to calc, if
  98.        such a value is in the history list (null otherwise).
  99.  
  100.        It would be very helpful to use the history values in
  101.        subsequent equations.
  102.  
  103.     *  Add a builtin that returns command as a string from the
  104.        history list.  As an example:
  105.  
  106.         history(-10)
  107.     
  108.        returns a string containing the 10th command on the
  109.        history list, if a such a value is in the history list 
  110.        (empty string otherwise).  And:
  111.  
  112.         history(23)
  113.     
  114.        return the string containing the 23rd command given to calc, if
  115.        such a value is in the history list (empty string otherwise).
  116.  
  117.        One could use the eval() function to re-evaluate the command.
  118.  
  119.     *  Restore the command number to calc prompts.  When going back
  120.        in the history list, indicate the command number that is
  121.        being examined.
  122.  
  123.        The command number was a useful item.  When one is scanning the
  124.        history list, knowing where you are is hard without it.  It can
  125.        get confusing when the history list wraps or when you use
  126.        search bindings.  Command numbers would be useful in
  127.        conjunction with positive args for the history() and histval()
  128.        functions as suggested above.
  129.  
  130.     *  Add a builtin that returns the current command number.
  131.        For example:
  132.  
  133.         cmdnum()
  134.  
  135.        returns the current command number.
  136.  
  137.        This would allow one to tag a value in the history list.  One
  138.        could save the result of cmdnum() in a variable and later use
  139.        it as an arg to the histval() or history() functions.
  140.  
  141.     *  Add a builtin to determine if an object as been defined.
  142.        For example:
  143.  
  144.         isobjdef("surd")
  145.  
  146.        would return true if one had previously defined the
  147.        surd object.  I.e., if "obj surd {...};" had been
  148.        executed.
  149.  
  150.        One cannot redefine an object.  If a script defines an object,
  151.        one cannot reload it without getting lots of already defined
  152.        errors.  If two scripts needed the same object, both could
  153.        define it and use isobjdef() to avoid redefinition problems.
  154.  
  155.     *  Add a builtin to determine if a function as been defined.
  156.        For example:
  157.  
  158.         isfunct("foo")
  159.  
  160.        would return true if foo has been defined as a function.
  161.  
  162.     *  Permit one to destroy an object.
  163.  
  164.        What if one does want to redefine an object?  Consider the case
  165.        where one it debugging a script and wants to reload it.  If
  166.        that script defines an object you are doomed.  Perhaps
  167.        destroying a object would undefine all of its related functions
  168.        and values?
  169.  
  170.     *  Port calc to a 64 bit machine, or a machine where long was larger
  171.        than an int.
  172.  
  173.        There are at least two issues here.  The first is fix places
  174.        where calc assumes that an int and a long are the same size.
  175.        The second and more important would be to change calc so that
  176.        it could be configured to work with a base of 2^32.  (Right now
  177.        calc is somewhat wired to use base 2^16).
  178.  
  179.        In other words first make calc 64 bit safe, then increase
  180.        performance on 64 bit machines by allowing one to configure
  181.        (via the Makefile) calc to use an larger internal base.
  182.     
  183.     *  One some machines (such as the 486), floating point can be faster 
  184.        than integer arithmetic.  Often such floating point would allow
  185.        for a larger base than 2^16, allowing calc to run even faster.
  186.        Allow calc to take advantage of such hardware.
  187.     
  188.     *  Add NAN's (Not A Number's) to calc.  Where is it reasonable, change 
  189.        calc to process these values in way similar to that of the IEEE 
  190.        floating point.
  191.     
  192.     *  Add a factoring builtin functions.  Provide functions that perform 
  193.        multiple polynomial quadratic sieves, elliptic curve, difference 
  194.        of two squares, N-1 factoring as so on.  Provide a easy general 
  195.        factoring builtin (say factor(foo)) that would attempt to apply
  196.        whatever process was needed based on the value.
  197.  
  198.        Factoring builtins would return a matrix of factors.
  199.  
  200.        It would be handy to configure, via config(), the maximum time
  201.        that one should try to factor a number.  By default the time
  202.        should be infinite.  If one set the time limit to a finite
  203.        value and the time limit was exceeded, the factoring builtin
  204.        would return whatever if had found thus far, even if no new 
  205.        factors had been found.
  206.  
  207.        Another factoring configuration interface, via config(), that
  208.        is needed would be to direct the factoring builtins to return
  209.        as soon as a factor was found.
  210.  
  211.     *  Allow one to disable, via config, the printing of the leading ~
  212.        on truncated numeric values.
  213.  
  214.        Sometimes the leading ~'s are more annoying than helpful.
  215.     
  216.     *  Allow one to disable, via config, the printing of the leading tab 
  217.        when printing the value of a command that one just typed.
  218.  
  219.        Most of the time, the leading tab is reasonable.  Sometimes
  220.        it is not.  It would be helpful if one could turn off the
  221.        tab in such cases.
  222.     
  223.     *  Allow one to config calc break up long output lines.
  224.  
  225.        The command:  calc '2^100000'  will produce one very long
  226.        line.  Many times this is reasonable.  Long output lines
  227.        are a problem for some utilities.  It would be nice if one
  228.        could configure, via config(), calc to fold long lines.
  229.  
  230.        By default, calc should continue to produce long lines.
  231.  
  232.        One option to config should be to specify the length to
  233.        fold output.  Another option should be to append a trailing
  234.        \ on folded lines (as some symbolic packages use).
  235.  
  236.     *  Add scanf() and fscanf() functions.
  237.  
  238.        The scanf function should be able to handle both long lines
  239.        and split lines with trailing \'s.  It should also be able
  240.        to ignore the leading ~.
  241.  
  242.